One way to extend the capabilities of computers and applications to make decisions automatically is to provide access to a file containing rules. Then, if a user desires to change operations performed or conditions necessary for performance, the user need only modify the rule. The user does not need to rewrite code for an application every time a change is necessary. Rather the user goes to the rules file and edits the rule.
One example of the use of rules is the logical topology of a network describing the path taken by data from one node to another. The rule represents the path taken at each node with logical statements. For example, a dynamic cluster membership policy comprises of a rule that can be edited. An exemplary dynamic cluster membership policy rule could be made up of various rule portions and/or rule groups such as “nodegroup like ‘node*’ AND nodeproperty$memory=‘2000’).” The membership policy helps dynamically define the servers that should be associated with this dynamic cluster. The above exemplary rule would match any server on a node named ‘node*’ (where ‘*’ is a wildcard) with node property named ‘memory’ that has a value of ‘2000’. It is important for administrators to update this membership policy as conditions in their environment change. It is also equally important for administrators to be able to look at the membership policy (or rule) and see what they have defined as the membership rules.
Another example of rule use is a work class classification rule. Work class classification rules have a different purpose than membership policy rules. These rules help administrators define what, when and where different requests should be routed. For example, a rule such as—clientipv4 like ‘192.168.0.*’ AND time$Tues=‘13:00’)—matches any request coming in that is coming from the IP address of ‘192.168.0.*’ (where ‘*’ is a wildcard) at 1 pm on any Tuesday. The portion of the rule—clientipv4 like ‘192.168.0.*—is referred to as a rule element or a rule portion. As used herein rule element and rule portion shall have the same meaning. The portion of the rule—AND—is an operator. As used herein, the term operator shall mean AND or OR. As used herein, a rule group is a logical grouping of two or more elements and one or more connectors. In other words a rule group is a subset of a rule that has at least two elements and a connector.
Once the rule is defined it is also possible to associate specific actions to take when the rule is satisfied. In this case, once the request is determined to match a rule it can then take this action. Typically this can be to reject service to the request, allow the request to reach the web application, or redirect to a different location. As used herein, the term rule means a logical statement comprising a rule element alone or a combination of rule elements and operators.
Logical statements, or rules, quickly grow very long and hard to read. Some editing tools exist. For example, FIG. 2 depicts prior art graphical user interface 170 for editing rules regarding electronic mail. Line 150 is a rule element which states “sender contains miksmith.” Line 152 comprises an operator “AND” and a second rule element “sender contains yes.” Line 154 comprises an operator “AND.” Line 156 comprises a rule element “sender does not start with helloMyNameIs.” Line 158 comprises an operator “AND.” Line 160 comprises an unfinished rule element “sender contains . . . ” Thus in the example the rule would be “Sender contains miksmith AND sender contains yes AND sender does not start with helloMyNameIs.” The unfinished rule element is not included. The graphical user interface only allows changes to certain portions of a rule element and to add rule elements at the end. But it does not allow changes to the order of the elements. Moreover, it does not provide a combined view of the entire rule and the rule portions. Finally, it does not allow a user to choose where to add in additional rule portions, but only adds rules portions to the end of the rule.
Therefore, a need exists for a way to easily reorder rule portions so that a user does not have to delete the rule portion from a first location and then manually add the rule portion back into a second location. A need exists for a way to edit rules without having to retype portions of the rule, a process in which errors can occur. A further need exists for a method of editing rules where additional rule portions may be added anywhere and not only at the end of the rule. A further need exists to make rules easier to read for editing, they can be shown in a hierarchical tree view, with complex rule portions being further expandable.